NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/9486

Internet Message Format | 1996-08-05 | 4.0 KB

Path: keats.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.c
Subject: Re: Segmentation Fault ???
Date: 10 Mar 1996 13:56:44 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <4hsa7i$[e-mail]> <4huis1$[e-mail]> <[e-mail]> <4hvaq3$[e-mail]>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca

In article <4hvaq3$[e-mail]>,
Toby K Hay <[e-mail]> wrote:
 >Kazimir Kylheku ([e-mail]) wrote:
 >
 >: It means that you are making errors in your code that the Turbo C environment
 >: doesn't catch. The bus error is likely caused by invoking
 >: implementation-specific behavior that is in contravention to standard C:
 >: converting a pointer to one that has a stricter alignment. On many of the
 >: processors used in UNIX workstations, the address of a long word has to be
 >: divisible by four. On a 68000 processor, the address of a 16-bit word has to be
 >: divisible by two.
 >: If you fail to meet these alignment restrictions, the hardware will trigger an
 >: exception, and the UNIX kernel will send a SIGBUS signal to your program.
 >
 >Would lint catch this for me, or will I have to learn about alignment
 >restrictions to run my program?

I'm ashamed to admit that I have never used lint except out of curiosity. Using
the GNU C compiler with all warnings turned on usually turns up some dirt. By
all means, try lint to see what it comes up with! It certainly won't hurt.

Alignment violations are not something that you should need to comb your code
for, unless you have written a great deal of code on your PC that makes such
violations!

It's not something that happens by accident; it's usually the result of an
explicit pointer conversion from one type to another.  Such conversions are
almost always a bad idea. You can only convert a strongly aligned type to a
less strong one. The char * always has the most relaxed alignment, though. So
you can safely convert an int * to a char *, but not vice versa.

Your compiler should be able to diagnose such conversions, unless they are done
through void * as an intermediary. Turn on all warnings. Try using 'gcc' if it
is available, with the arguments -Wall -pedantic.  If it is not available, have
the admin install it ASAP! :)

Also, the bus error may indicate other types of undefined or
implementation-defined behavior. If you are converting between int and char
pointers, you may also be making assumptions about the byte order, the size of
an integer or long and the like. In particular, using a character pointer to
access an integer object is a very bad thing!

If you wrote the code, you probably have a good idea where you did these kinds
of things. If you heavily depend on implementation-defined pointer behavior,
you may have to re-think and re-write portions of your code to make it more
portable.

 >From three replies I received via E-mail I understand that accessing
 >illegal memory is almost certainly caused by using uninitialized pointers
 >- something I will check my code for again.  But what determines the

Uninitialized pointers, forgetting arguments to unprototyped functions,
out-of-bounds array references, forgetting to check for NULL values from
functions that _can_ return NULL...  all of these are potential segfault
candidates.

 >limits of my malloc heap, stack, and so forth?  Can I request more memory
 >for these at the command line when I start the program?

You don't have to. Modern UNIX automagically adds memory to your address space
where no memory existed before. Normally, this means you can malloc() as much
as you want without worrying about hitting the wall. When your program exits,
the space is returned to the operating system.

There may be administrator-imposed per-user process limits on parameters such
as maximum size of a task. If not, the available RAM + swap space is usually
the limit on how much you can allocate.

--